1. Field of the Invention
The invention relates to flash memory cards and particularly to flash memory cards that can emulate the protocol of one type of flash memory using flash memory devices conforming to a different protocol.
2. Background
Linear flash memory devices have enjoyed wide and growing popularity in devices such as flash memory cards, combination devices such as flash/modem PC cards, and embedded systems such as routers, hubs, switches used in networks. Flash memories are solid state chips that can store data without requiring power to retain their data. Thus, they are often used in places where one might otherwise use a hard disk of a floppy disk to store data. However, because they are solid state devices, they are more rugged and can be made into very small sizes. One example is the very popular linear flash memory PCMCIA card.
Referring to FIG. 1, the basic components of flash memory devices are a controller 110 and one or more flash memory chips 120. A host device 100 reads or writes data from/to the flash memory chip 120 via an interface 105 such as a PCMCIA interface, USB, or any other device. The accessing of the desired memory part of the memory inside the flash memory chip 120 that contains the desired data is called xe2x80x9caddressing.xe2x80x9d In prior art flash memory devices, the controller ordinarily simply frames and queues addressing signals so that the flash memories receive them in the correct format. Advanced flash devices can provide further functionality to the controller, for example, by keeping a record of bad memory cells and remapping addresses for those bad cells, by eliminating errors in bad cells using error correcting codes, by load leveling to spread wear over all cells of the flash memory.
There is a set of steps that must be done for a host computer to address a given part of the memory. These steps are performed by two sets of components: the controller 110 on the device, such as the flash PC card, and addressing hardware (not shown) in the flash memory chips themselves 120. To read or write data, besides the data involved (e.g., a series of bits that represents the character xe2x80x9cA,xe2x80x9d) the host system 100 has to generate a command, for example, a command to read from a particular memory location on the flash chip 120. Flash chips are currently made to understand two sets of commands, which the controller can generate. One set of commands is standard (called xe2x80x9cCommand-Command Interfacexe2x80x9d or xe2x80x9cCCIxe2x80x9d) and most manufacturers provide support for this set of commands. Another set of commands is specific to the manufacturer of the flash chips, and if a controller is designed to generate the commands for a particular manufacturer, the controller cannot be used with another manufacturer""s chips. Also, sometimes device manufacturers design their systems (the xe2x80x9chostxe2x80x9d systems, which are the ones the flash cards are plugged into) to use the specific command set of the manufacturer to achieve extended capabilities or higher speed that are available from the manufacturer-specific command protocol. However, this has the disadvantage that it locks the card manufacturer into a particular flash manufacturer""s specification so long as the card manufacturer is supplying cards to the host system manufacturer. Thus, the card manufacturer is prevented from switching to a different supplier of flash memory chips, should cost performance characteristics of that different supplier make that an attractive option.
One type of flash memory device that translates between one type of command and another type of command is an ATA-type controller. The host applies block-level commands to the flash device and an internal controller translates these to linear addresses. Thus, in such translations, the numbers of input and output address signal lines may differ on each side of the translation.
The invention provides a translator inside a flash memory controller that translates commands from a host system conforming to the protocol of one flash chip manufacturer into commands that are recognized by the flash chips of another manufacturer. The result is that host system manufacturers may design systems to use the extended capabilities of a particular flash chip manufacture""s command set knowing that the chip""s of another manufacturer could be substituted in the flash memory cards the host system accepts. This allows the supplier of the cards to supply cards with the highest possible cost/performance ratio.
One of the issues facing the designer of an interface is that there is that there is rarely a one-to-one correspondence of states between the state-machine of one protocol and another. Thus, translating commands from one device to emulate another can present problems. Another source of difficulty is when the host is designed to expect certain responses at a certain time. If there is a delay, the host may never believe a valid response may be forthcoming.
There are conditions that can help to get around these difficulties. First, commands from one protocol can be delivered to a controller while the controller isolates the flash memory from the host. After the commands of protocol 1 are received and validated as a recognized command, the controller can generate the commands using the second protocol. This is a robust mechanism for working around the lack of a one-to-one correspondence between states during command and argument-passing from the host to the controller and what would otherwise exist if the controller were simply addressing the flash memory directly. Second, the flash memory that is used to substitute for the one the host is programmed to expect should be faster than the latter. In this way, the time lag between host sending commands to the controller and the controller generating new commands in tandem, then waiting for the response is not very great. Where possible, if a portion of the protocol 2 command can be generated before a complete protocol 1 command is validated by the controller, one or more bus cycles can be saved. In this case, if the protocol 1 command is invalid, the controller can deliberately force a invalid command that would reset the flash memory receiving the protocol 2 command.
The invention will be described in connection with certain preferred embodiments, with reference to the following illustrative figures so that it may be more fully understood. With reference to the figures, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.